如何在Scrum中抛弃估算活动

简介

软件开发中的估算是个庞大的话题，我会在一系列文章中讨论这个话题，这是第一篇。

我们会在很多不同场景下做估算，在这一系列文章中，我会尽可能涵盖所能想到的场景，但观点始终如一：在软件项目中，不应该基于估算做决定。对软件产品提供方及其内部和外部客户而言，有比估算更好的替代方案，既经济又人性化。其中很多方案已应用于公司实践，发布产品给真实客户，并产生了巨大的影响。

考虑到这个话题之繁杂，本文只针对特定场景，即一个scrum团队（或其他采用迭代式产品开发方法的团队）不使用估算来发布软件产品的场景。规模扩大或缩小（增加或减少团队成员）的问题，在随后一篇关于项目组合估算的帖子中会谈及。

我们会按时发布吗？

软件开发团队在项目开始时以及项目过程中经常被问到这个问题，这也是很多人认为需要估算的主要原因。然而，多数人都在凭猜测做出的预测中挣扎着寻找确定性，这不是很讽刺吗？我们都知道或者至少会怀疑，那不过是凭空猜数而已。我们不知道或不理解解决方案或业务领域，仅仅安慰自己说这是个“经验性的”或“快速而粗糙的”猜测，并为我们用这种方法做出重要商业决策进行辩解。

开发软件本质上不可预测且无法重复。开发软件时，我们不能像制造汽车零部件那样，很容易地把工作分解成同样尺寸、可重复生产的部件。与汽车生产不同，软件完成前我们并不知道它到底长什么样。既然如此，怎么可能一开始就把工作分解好呢？软件产品的每个迭代，新增的功能都是不同的。软件开发是创造性的、不断变化的尝试，解决方案往往会在开发过程逐步呈现。正因如此，软件项目中范围不可能固定不变。即便真的可以固定范围，越来越多的人也认识到这是不可取的，因为这会阻碍（至少没有拥抱）涌现的设计、需求、变化和革新。如果我们认可项目的范围始终在变，那么就不得不承认，当我们急急忙忙地想要“按时”“在预算内”发布所谓固定的范围时，交付日期就成了不断移动的球门柱。

如果说“按时”和“在预算内”通常是基于一个估算，而这个估算是交付软件满足预订的需求所需要的时间和花费，而不是具体的时间点或者预算约束，那么我们完全有可能比最初估算的晚一些交付软件。我们也可能提前交付，或者我们刚刚好交付。问题是，不管结果如何，估算有多“正确”真的很重要吗？估算我们的工作对发布伟大的软件或投资回报率真的会有正面或负面影响吗？


愿景是核心

为了构建软件，我们需要有一个清晰的愿景，并对什么是成功达成共识。 当开始一个有潜在价值的软件计划时，我们需要很好地理解高层次目标，而不是达成目标的细节。这样在真正迭代的时候，我们就能够把下次迭代如何提高产品质量的即时策略与这些目标结合起来，比如接下来要构建什么，也就是Product Baclog里级别最高的条目。有人会试图估算多久能够发布软件以达到一个或者多个高层次目标，然后基于这个估算来做出真实的决策，我认为这种方法很有问题。难道我们不想让解决方案和架构涌现出来吗？难道我们不想在产品逐步演化、在用户面前变得越来越真实的时候，拥抱变化为客户赢得竞争优势吗？这些都是敏捷宣言里面的关键原则。在真正敏捷的软件开发方法中，我相信这些原则位于核心地位。

移除未知

46 32508 46 15231 0 0 4629 0 0:00:07 0:00:03 0:00:04 4629其依赖估算的准确性来提高可预测性，不如移除成本和发布日期的未知因素，把未知变成已知。Product Owner可以使用具体的预算和（或）时间约束来确定发布日期：比如“澳网开始三天前发布澳网公开赛应用”是确定的时间约束，还有“我们要用$30,000去做项目”是一个明确的资金预算约束。团队可以根据约束条件确定产品增量的交付日期（比如每个Sprint的结束日期），这样团队在Sprint中就能把精力集中在产品的迭代上，并为更早发布和（或）低于预算的发布创造机会。每天凭一时冲动而改变优先级并不好。在没有实际预算或者发布日期的时候，这种方法也很有用。不过一支能够持续发布的成熟团队（和组织），就没必要预先确定增量的发布日期了。

估算Sprint速率是一种浪费

与其为了估算时间预先定下解决方案，或者每个Sprint预测完成多少个故事点，我认为团队更应该一开始就承诺：在给定的日期、资金条件下，全力开发和交付最好的产品。在我看来，按速率制定发布计划（“到发布日我们可以交付多少点数？”或“按照当前的需求范围和速率，什么时候可以发布”）与迭代方法（整体的、演进式的产品改善）是抵触的，这更像是纯粹的增量方法（按预先定义的Product Backlog逐个交付功能）。

当我们做估算并使用速率作为计划工具时，就是在假设一个时间段内能完成多少工作。为了让这个信息有用且有意义，我们需要记录很多东西（即：一份详细估算过的Product Backlog）。如果我说花在那些最终未交付的backlog条目上的时间和金钱都浪费掉了，大家应该不会有太多异议，至少从精益的理念来看如此。

花在那些最终交付了的backlog条目上的时间和金钱又如何呢？为了回答这个问题，我得再问个问题：“Product Owner曾经因为一个故事的点数较小而提高它的优先级吗？”如果答案是“否”，那我可以推断，在这种环境下所有的估算都是浪费，因为估算不会带来任何决策的变化（Product Owner仅根据故事的价值排序）；如果答案是“是”，那就是估算控制了决策，而我认为决策应该基于价值。先估算backlog，再根据速率制定发布计划是一种基于成本的方法。尽管成本对于软件项目和商业很重要，但如果仅仅根据成本来决策，那么我们现在使用的一些伟大软件（例如Google、Fackbook、Apple、Yahoo、Spotify等公司的许多产品）永远不会被创造出来，这也可以解释为什么世界上有那么多昂贵、臃肿的垃圾软件。

迭代，不要估算

我认为迭代（敏捷）开发完全是关于如何在固定成本下，用实验方法而非猜测，基于用户价值和（或）商业价值做出决策。所谓固定成本是指一支固定的团队（例如Spotify公司的“squad”模式）按照预定的时间表发布。这个预定的时间表不同于“截止日期”：截止日期是基于想像中的约束条件为“确定的”范围设定的发布日期。固定的成本和交付日期，让我们更有信心去拥抱开发伟大产品时出现的宝贵的不确定性。

此外，固定的交付日期并不意味着我们在发布之日就停止开发产品，我们也许早已停止开发或者选择继续开发。固定的交付日期仅仅意味着，我们会根据开发过程中涌现的或潜在的价值不断决定继续或停止，而不是根据特定解决方案的估算成本做决定。

专注于拆分

我认为，从团队的角度出发，提高拆分用户故事的能力，价值远远大于“提升速度”。而且一定要在用到时才拆分用户故事，任何过早的拆分都是浪费。对我而言，高效能团队能够频繁交付可用的产品新功能，迅速得到用户反馈，并为用户创造价值。很明显，新功能越小，交付才会越频繁。频繁的交付缩短了反馈周期，为Product Owner赢得了更多的学习机会，并能更灵活地调整优先级：涌现的新功能优先级也许会高于原先以为需要但已贬值的功能，甚至产品的方向都可能完全改变。在我看来，这一点才适应真正的商业敏捷力。

当团队能够频繁地实现产品变更并交到用户手上时，每个Sprint交付了多少用户故事或功能点已经不重要了。在我看来，这才是软件项目努力拥抱敏捷方法的关键原因。但是，只有抛弃了估算，我们才能释放全部的生产力来为用户创造最棒的产品。

更多精彩内容请长按一下二维码，关注我们的微信公众号：互联网plus管理新范式。

• 回复：估算，进一步了解估算”三不“原则

互联网plus管理新范式

Agilean官方博客平台

微信号

iPlusLeadership

点击

阅读原文

访问英文博客